Electronic trading systems accept bids and offers in the form of orders, which are also referred to as real orders because they consist of data entered by traders either directly or by computing devices under their control. Based on the nature of the exchange, electronic trading systems generally perform matching using the following procedure. First, a new request is received. The request may be an order, an order modification, or an order cancellation. Second, the new request is evaluated against the existing order book and matching is performed, if possible. Third, once processing has been finished, messages are sent out to notify the marketplace of the actions performed, which updates the current state of the market. Finally, the electronic trading system checks to see if there is any quantity remaining to be rested on the order book.
This sequence is mandated by the business rules used by electronic trading systems to ensure market integrity. It is a requirement that orders be matched in a one-at-a-time serialized manner.
Of these steps or sequence, the preparation and communication of messages has been found to require the great amount of processing time. For example, messages corresponding to each of the executed trades need to be built and sent out. Since traders need to be able to respond to the events generated, these actions must be completely executed before processing of the next request can begin.
Exchanges that host electronic trading systems using match engines are constantly striving to shorten their response time and thus increase the number of matches performed per unit of time. At some point, performance optimizations options based upon the single threaded matching logic and code will be exhausted. A need for a fundamental architectural change arises.
What is needed is an approach that could significantly improve the performance of order matching, especially at peak times, when a burst of orders is received by the trading engine.